Quick guide to various init implementations
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Linux init systems tend to fall into several groups roughly outlined below.
The list is not comprehensive, its goal is only to give some idea on how
sninit fits within the big picture. For a reasonably complete list of init
systems, see http://without-systemd.org/wiki/index.php/Init .

Most implementations have a notion of an "entry". An entry is a command
to be run by init. W-entries should only be run once and S-entries should be
respawned when they die. It is assumed that system startup consists of running
some W-entries and then spawning some S-entries.

---

A number of inits including sninit are based on the original SysV init,
which is probably the oldest among well-known init implementations.
These tend to have an ordered list with S-entries and W-entries intermixed.

    http://savannah.nongnu.org/projects/sysvinit (the original)
    http://www.busybox.net/ busybox init
    https://github.com/troglobit/finit
    https://github.com/arsv/sninit

David J. Bernsteins's daemontools was an early and highly influential
attempt at writing a reliable init system, which spawned a bunch of
descendant implementations.

Their shared feature is a dedicated respawner with uniform, unordered
list of S-entries, and often a dedicated supervisor process for each
spawned entry. Handling of sequential W-entries is typically delegated
to some kind of shell scripts.

    http://cr.yp.to/daemontools.html (the original)
    http://untroubled.org/daemontools-encore/
    http://smarden.org/runit/
    http://skarnet.org/software/s6/

Dependency-based init systems manage a tree of implicitly-ordered entries.
The order in which the entries are started is determined at runtime,
in a way similar to how make orders targets to be rebuilt.

    http://upstart.ubuntu.com/
    http://www.freedesktop.org/wiki/Software/systemd/
    http://uselessd.darknedgy.net/ (attempt to reimplement systemd)
    https://github.com/android/platform_system_core/tree/master/init
    https://github.com/davmac314/dinit

Another approach to init design is to drop respawner altogether,
with the assumption that the daemons are truly immortal.
PID files and daemon(3) originate from this branch of design.

    SysV-style initscripts, several implementations, for instance:
        https://git.fedorahosted.org/git/initscripts.git
    BSD rc scripts derivatives, see intro here:
        https://www.freebsd.org/doc/en/books/porters-handbook/rc-scripts.html
    OpenRC, arguably:
        https://wiki.gentoo.org/wiki/Project:OpenRC
    Various "minimal init" projects:
        https://gist.github.com/rofl0r/6168719 (minit aka minimal init)
        http://git.suckless.org/sinit
        https://github.com/Yelp/dumb-init

Initscripts usually need a dedicated reaper process. Common approach back
at the time was to use sysvinit, which also handled the few strict S-entries
like gettys. Another approach is to use a dedicated minimalistic reaper like
minit or suckless init.

POSIX shells with "wait" built-in typically allow implementing a simple
reaper-only init as a shell script, though it rarely makes much sense.

---

There's a lot of confusion about the System V init system and its derivatives.

System V was mostly initscripts-based, not sysvinit-based.

The only respawning entries were gettys, all daemons were started unsupervised
by initscripts. Most of the bad rap about SysV-style init systems is in fact
about SysV-style initscripts.

To clarify: sysvinit is a binary that reads /etc/inittab and spawn only
the entries described there. Initscripts are shell scripts that go through
/etc/rc.d, /etc/rcN.d, /etc/init.d depending on implementation and run stuff
like "/etc/init.d/httpd start". They are not a part of sysvinit, but they
are a part of System V init system.

Very few systems used sysvinit as a proper supervisor.
Those that did had all their daemons listed directly in /etc/inittab.
